#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
c93cc8ed |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
part: Remove <common.h> and add needed includes Remove <common.h> from all "part/" files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1e94b46f |
|
14-Sep-2023 |
Simon Glass <sjg@chromium.org> |
common: Drop linux/printk.h from common header This old patch was marked as deferred. Bring it back to life, to continue towards the removal of common.h Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
782c7f1b |
|
02-Sep-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: rename disk_partition_type_uuid() Rename disk_partition_type_uuid to disk_partition_type_guid. Provide function descriptions for the getter and setter. Fixes: bcd645428c34 ("part: Add accessors for struct disk_partition type_uuid") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
fbd644e7 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: efi: Add debugging for the signature check Add a little more debugging for the initial signature check. Drop the pointless check for NULL. Also set a log category while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
bcd64542 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: Add accessors for struct disk_partition type_uuid This field is only present when a CONFIG is set. To avoid annoying #ifdefs in the source code, add accessors. Update all code to use it. Note that the accessor is optional. It can be omitted if it is known that the option is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
c5f1d005 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: Add accessors for struct disk_partition uuid This field is only present when a CONFIG is set. To avoid annoying #ifdefs in the source code, add accessors. Update all code to use it. Note that the accessor is optional. It can be omitted if it is known that the option is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
7ed781fb |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: efi: Use desc instead of dev_desc The dev_ prefix is a hangover from the pre-driver model days. The device is now a different thing, with driver model. Update the efi code to just use 'desc'. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0b11c3da |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
Correct SPL use of PARTITION_TYPE_GUID This converts 1 usage of this option to the non-SPL form, since there is no SPL_PARTITION_TYPE_GUID defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org> |
#
3e62adc4 |
|
20-Oct-2022 |
Simon Glass <sjg@chromium.org> |
disk: Drop debug messages in part_efi This is monstrously verbose when something goes wrong. It should work by recording the problem and reporting it (once) at the command level. At present it sometimes outputs hundreds of lines of CRC mismatches. For now, just silence it all. GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** ... While we are error, remove the '*** ERROR: ' text as it is already clear that this is unexpected Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f337fb9e |
|
11-Oct-2022 |
Simon Glass <sjg@chromium.org> |
fs: Quieten down the filesystems more When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <masahiroy@kernel.org> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
c93cc8ed |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
part: Remove <common.h> and add needed includes Remove <common.h> from all "part/" files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1e94b46f |
|
14-Sep-2023 |
Simon Glass <sjg@chromium.org> |
common: Drop linux/printk.h from common header This old patch was marked as deferred. Bring it back to life, to continue towards the removal of common.h Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
782c7f1b |
|
02-Sep-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: rename disk_partition_type_uuid() Rename disk_partition_type_uuid to disk_partition_type_guid. Provide function descriptions for the getter and setter. Fixes: bcd645428c34 ("part: Add accessors for struct disk_partition type_uuid") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
fbd644e7 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: efi: Add debugging for the signature check Add a little more debugging for the initial signature check. Drop the pointless check for NULL. Also set a log category while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
bcd64542 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: Add accessors for struct disk_partition type_uuid This field is only present when a CONFIG is set. To avoid annoying #ifdefs in the source code, add accessors. Update all code to use it. Note that the accessor is optional. It can be omitted if it is known that the option is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
c5f1d005 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: Add accessors for struct disk_partition uuid This field is only present when a CONFIG is set. To avoid annoying #ifdefs in the source code, add accessors. Update all code to use it. Note that the accessor is optional. It can be omitted if it is known that the option is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
7ed781fb |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: efi: Use desc instead of dev_desc The dev_ prefix is a hangover from the pre-driver model days. The device is now a different thing, with driver model. Update the efi code to just use 'desc'. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0b11c3da |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
Correct SPL use of PARTITION_TYPE_GUID This converts 1 usage of this option to the non-SPL form, since there is no SPL_PARTITION_TYPE_GUID defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org> |
#
3e62adc4 |
|
20-Oct-2022 |
Simon Glass <sjg@chromium.org> |
disk: Drop debug messages in part_efi This is monstrously verbose when something goes wrong. It should work by recording the problem and reporting it (once) at the command level. At present it sometimes outputs hundreds of lines of CRC mismatches. For now, just silence it all. GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** ... While we are error, remove the '*** ERROR: ' text as it is already clear that this is unexpected Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f337fb9e |
|
11-Oct-2022 |
Simon Glass <sjg@chromium.org> |
fs: Quieten down the filesystems more When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <masahiroy@kernel.org> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
1e94b46f |
|
14-Sep-2023 |
Simon Glass <sjg@chromium.org> |
common: Drop linux/printk.h from common header This old patch was marked as deferred. Bring it back to life, to continue towards the removal of common.h Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
782c7f1b |
|
02-Sep-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: rename disk_partition_type_uuid() Rename disk_partition_type_uuid to disk_partition_type_guid. Provide function descriptions for the getter and setter. Fixes: bcd645428c34 ("part: Add accessors for struct disk_partition type_uuid") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
fbd644e7 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: efi: Add debugging for the signature check Add a little more debugging for the initial signature check. Drop the pointless check for NULL. Also set a log category while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
bcd64542 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: Add accessors for struct disk_partition type_uuid This field is only present when a CONFIG is set. To avoid annoying #ifdefs in the source code, add accessors. Update all code to use it. Note that the accessor is optional. It can be omitted if it is known that the option is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
c5f1d005 |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: Add accessors for struct disk_partition uuid This field is only present when a CONFIG is set. To avoid annoying #ifdefs in the source code, add accessors. Update all code to use it. Note that the accessor is optional. It can be omitted if it is known that the option is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
7ed781fb |
|
24-Aug-2023 |
Simon Glass <sjg@chromium.org> |
part: efi: Use desc instead of dev_desc The dev_ prefix is a hangover from the pre-driver model days. The device is now a different thing, with driver model. Update the efi code to just use 'desc'. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0b11c3da |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
Correct SPL use of PARTITION_TYPE_GUID This converts 1 usage of this option to the non-SPL form, since there is no SPL_PARTITION_TYPE_GUID defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org> |
#
3e62adc4 |
|
20-Oct-2022 |
Simon Glass <sjg@chromium.org> |
disk: Drop debug messages in part_efi This is monstrously verbose when something goes wrong. It should work by recording the problem and reporting it (once) at the command level. At present it sometimes outputs hundreds of lines of CRC mismatches. For now, just silence it all. GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** ... While we are error, remove the '*** ERROR: ' text as it is already clear that this is unexpected Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f337fb9e |
|
11-Oct-2022 |
Simon Glass <sjg@chromium.org> |
fs: Quieten down the filesystems more When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <masahiroy@kernel.org> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
0b11c3da |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
Correct SPL use of PARTITION_TYPE_GUID This converts 1 usage of this option to the non-SPL form, since there is no SPL_PARTITION_TYPE_GUID defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org> |
#
3e62adc4 |
|
20-Oct-2022 |
Simon Glass <sjg@chromium.org> |
disk: Drop debug messages in part_efi This is monstrously verbose when something goes wrong. It should work by recording the problem and reporting it (once) at the command level. At present it sometimes outputs hundreds of lines of CRC mismatches. For now, just silence it all. GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** ... While we are error, remove the '*** ERROR: ' text as it is already clear that this is unexpected Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f337fb9e |
|
11-Oct-2022 |
Simon Glass <sjg@chromium.org> |
fs: Quieten down the filesystems more When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
3e62adc4 |
|
20-Oct-2022 |
Simon Glass <sjg@chromium.org> |
disk: Drop debug messages in part_efi This is monstrously verbose when something goes wrong. It should work by recording the problem and reporting it (once) at the command level. At present it sometimes outputs hundreds of lines of CRC mismatches. For now, just silence it all. GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** ... While we are error, remove the '*** ERROR: ' text as it is already clear that this is unexpected Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f337fb9e |
|
11-Oct-2022 |
Simon Glass <sjg@chromium.org> |
fs: Quieten down the filesystems more When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
f337fb9e |
|
11-Oct-2022 |
Simon Glass <sjg@chromium.org> |
fs: Quieten down the filesystems more When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
fc614d20 |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
disk: Use Makefile to omit partition drivers At present these files have an #ifdef covering the whole file. Move the condition to the Makefile instead. Add BLK to the condition since future patches will adjust things so that HAVE_BLOCK_DEVICE is only for SPL, but the partition drivers are needed in U-Boot proper too. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
1291c2d4 |
|
09-May-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: incorrect message in is_gpt_valid() alloc_read_gpt_entries() writes differentiated error messages. The caller is_gpt_valid() should not write an extra possibly wrong message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
5c783b54 |
|
22-Apr-2022 |
Philippe Reynes <philippe.reynes@softathome.com> |
disk: part_efi: add support to repair gpt table If a gpt table is corrupted (after a power cut for example), then the gpt table should repaired. The function gpt_repair_headers check if at least one gpt table is valid, and then only write the corrupted gpt table. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
da158ec5 |
|
22-Jan-2022 |
Tom Rini <trini@konsulko.com> |
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi Pull request for efi-2022-04-rc1-2 Documentation: * describe printf() format codes UEFI * enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048 General * simplify printing short texts for GUIDs * provide a unit test for printing GUIDs
|
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
a4492eee |
|
15-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: simplify part_print_efi() Use printf code %pUs to print the text representation of the partition type GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
504dbd22 |
|
11-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: gpt: print all partitions For GPT partition tables the 'part list' command stops at the first invalid partition number. But Ubuntu has images with partitions number 1, 12, 13, 14, 15 In this case only partition 1 was listed by 'part list'. Fixes: 38a3021edc54 ("disk: part_efi: remove indent level from loop") Reported-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
7de8bd03 |
|
07-Aug-2021 |
Simon Glass <sjg@chromium.org> |
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
a594b41f |
|
02-Jul-2021 |
Simon Glass <sjg@chromium.org> |
disk: Tidy up #ifdefs in part_efi This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it. There was some discussion about adjusting Kconfig or making HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is not feasible. Such changes can be undertaken separate from the goal of this series. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
d4693383 |
|
08-Mar-2021 |
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> |
disk: gpt: verify alternate LBA points to last usable LBA The gpt command require the GPT backup header at the standard location at the end of the device. Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> |
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> |
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com> |
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de> |
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> |
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com> |
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com> |
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@foss.st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com> |
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> |
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> |
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com> |
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> |
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> |
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2] |
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com> |
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com> |
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com |
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> |
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> |
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> |
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> |
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org> |
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com> |
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de> |
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com> |
#
40684ddb |
|
11-Dec-2012 |
Łukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> |
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> |
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com> |
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> |
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> |
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> |
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> |
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> |
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> |
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de> |
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com> |
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org> |
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> |
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
4e9bd062 |
|
26-Jan-2021 |
Gary Bisson <gary.bisson@boundarydevices.com> |
disk: part_efi: update partition table entries after write Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
31ce367c |
|
20-Nov-2020 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
lib/uuid.c: change prototype of uuid_guid_get_str() There's no reason to require an appropriately sized output parameter for the string, that's error-prone should the table ever grow an element with a longer string. We can just return the const char* pointer directly. Update the only caller accordingly, and get rid of pointless ifdeffery in the header so that the compiler always sees a declaration and can thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled or not. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
643b5e7e |
|
17-Sep-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: typo Terra Bytes 512 * 2^32 bytes equals 2 tebibytes. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
ba06b3c5 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop uuid.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
25801acc |
|
19-Mar-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
part: detect EFI system partition Up to now for MBR and GPT partitions the info field 'bootable' was set to 1 if either the partition was an EFI system partition or the bootable flag was set. Turn info field 'bootable' into a bit mask with separate bits for bootable and EFI system partition. This will allow us to identify the EFI system partition in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
3db71108 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
0557d46b |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: ignore 'IGNOREME' GPT header found on cros eMMCs Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of the eMMC write protected and equipped with a dummy 'IGNOREME' GPT header - instead of spewing error messages about it, just silently try the backup GPT. Note: this does not touch the gpt cmd writing/verifying functions, those will still complain. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
20c568ca |
|
11-Apr-2019 |
Urja Rannikko <urjaman@gmail.com> |
disk: efi: unify code for finding a valid gpt There were 3 copies of the same sequence, make it into a function. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
#
06e921b1 |
|
14-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: avoid unaligned pointer error When building with GCC 9.1 an error occurs: disk/part_efi.c: In function ‘gpt_verify_partitions’: disk/part_efi.c:737:49: error: taking address of packed member of ‘struct _gpt_entry’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 737 | gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name, | ~~~~~~~~^~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1 make: *** [Makefile:1594: disk] Error 2 Adjust gpt_convert_efi_name_to_char() to accept unaligned strings. Reported-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
5375ee50 |
|
05-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: buffer overflow in part_get_info_efi() In part_get_info_efi() we use the output of print_efiname() to set info->name[]. The size of info->name is PART_NAME_LEN = 32 but print_efiname() returns a string with a maximum length of PARTNAME_SZ + 1 = 37. Use snprintf() instead of sprintf() to avoid buffer overflow. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
716f919d |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt verify' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
1cfe9694 |
|
29-Apr-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
disk: efi: Fix memory leak on 'gpt guid' Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7de24b27 |
|
12-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
disk: efi: GUIDs should be const Make system_guid const. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
67b90522 |
|
01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
Rename GPT_HEADER_SIGNATURE to avoid conflict The current name conflicts with the Chrome OS verified boot library, which prevents it being built. That library uses a string whereas U-Boot uses a 64-bit hex value. Rename this in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
44ab2d32 |
|
09-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid initializer element is not constant When building with -pedantic the current definition of EFI_GUID() causes an error 'initializer element is not constant'. Currently EFI_GUID() is used both as an anonymous constant and as an intializer. A conversion to efi_guid_t is not allowable when using EFI_GUID() as an initializer. But it is needed when using it as an anonymous constant. We should not use EFI_GUID() for anything but an initializer. So let's introduce a variable where needed and remove the conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
955575c8 |
|
21-May-2018 |
Sam Protsenko <semen.protsenko@linaro.org> |
disk: efi: Correct backing up the MBR boot code In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") there was added the procedure for storing old boot code when doing "gpt write". But instead of storing just backup code, the whole MBR was stored, and only specific fields were replaced further, keeping everything else intact. That's obviously not what we want. Fix the code to actually store only old boot code and zero out everything else. This fixes next testing case: => mmc write $loadaddr 0x0 0x7b => gpt write mmc 1 $partitions In case when $loadaddr address and further memory contains 0xff, the board was bricked (ROM-code probably didn't like partition entries that were clobbered with 0xff). With this patch applied, commands above don't brick the board. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Cc: Alejandro Hernandez <ajhernandez@ti.com> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
1811a928 |
|
05-Feb-2018 |
Adam Ford <aford173@gmail.com> |
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
3cc56611 |
|
17-Nov-2017 |
Patrick Delaunay <patrick.delaunay@st.com> |
disk: efi: correct the allocation size for mbr header in stack use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation in stack to fix alloc issue in is_gpt_valid() this patch fix also issue for GPT partition handling with blocksize != 512 in set_protective_mbr() Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
|
#
bb021013 |
|
26-Oct-2017 |
Lukasz Majewski <lukma@denx.de> |
gpt: Use cache aligned buffers for gpt_h and gpt_e Before this patch one could receive following errors when executing "gpt write" command on machine with cache enabled: display5 factory > gpt write mmc ${mmcdev} ${partitions} Writing GPT: CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8] CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0] success! To alleviate this problem - the calloc()s have been replaced with malloc_cache_aligned() and memset(). After those changes the buffers are properly aligned (with both start address and size) to SoC cache line. Signed-off-by: Lukasz Majewski <lukma@denx.de>
|
#
ae0e0228 |
|
18-Oct-2017 |
Patrick Delaunay <patrick.delaunay@st.com> |
disk: efi: correct the overlap check on GPT header and PTE the partition starting at 0x4400 is refused with overlap error: $> gpt write mmc 0 "name=test,start=0x4400,size=0" Writing GPT: Partition overlap error! even if the 0x4400 is the first available offset for LBA35 with default value: - MBR=LBA1 - GPT header=LBA2 - PTE= 32 LBAs (128 entry), 3 to 34 And the command to have one partition for all the disk failed also : $> gpt write mmc 0 "name=test,size=0" After the patch : $> gpt write mmc 0 "name=test,size=0" Writing GPT: success! $> part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x01ce9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected Reviewed-by: Łukasz Majewski <lukma@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
|
#
b351ccf1 |
|
03-Oct-2017 |
Tom Rini <trini@konsulko.com> |
part_efi: In is_gpt_valid() check argument validity before allocation While this goes somewhat against normal coding style we should ensure that dev_desc is not NULL before we dereference it in allocation of legacy_mbr. Reported-by: Coverity (CID: 167292) Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
9b643e31 |
|
15-Sep-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: replace with error() with pr_err() U-Boot widely uses error() as a bit noisier variant of printf(). This macro causes name conflict with the following line in include/linux/compiler-gcc.h: # define __compiletime_error(message) __attribute__((error(message))) This prevents us from using __compiletime_error(), and makes it difficult to fully sync BUILD_BUG macros with Linux. (Notice Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().) Let's convert error() into now treewide-available pr_err(). Done with the help of Coccinelle, excluing tools/ directory. The semantic patch I used is as follows: // <smpl> @@@@ -error +pr_err (...) // </smpl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Re-run Coccinelle] Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ff98cb90 |
|
13-Sep-2017 |
Peter Jones <pjones@redhat.com> |
part: extract MBR signature from partitions EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones <pjones@redhat.com> [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
79c5912e |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Disable overlap check The current code checks that no partitions overlap with the GPT partition table using the offset of the first LBA usable for that partition. This works fine, unless you have a partition entry that is further away than it usually is and you want to create partitions in the gap between the GPT header and the GPT partition entries, for example to reflash a bootloader that needs to be set there. Rework the test to something a bit smarter that checks whether a partition would overlap with either the GPT header or the partition entries, no matter where it is on the disk. Partitions that do not have a start LBA specified will still start at the first LBA usable set in the GPT header, to avoid weird behaviours. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
47d7ee47 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: make gpt_fill_pte take the device descriptor The gpt_fill_pte will need to access the device block size. Let's pass the device descriptor as an argument. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
5276e8b6 |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: rework the partition start and size in gpt_fill_pte The start variable is only used inside a loop, and is never affected inside it, so it's a purely local variable. In the same way the partition size is accessed several times, so we can store it in a variable. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
89d33a2c |
|
23-Aug-2017 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
part: efi: Fix offset Both the config option and the DT options specify the offset to set the GPT at in bytes, yet the code treats those values as block numbers. Fix that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
#
73d6d18b |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
GPT: add accessor function for disk GUID In order to read the GPT, modify the partition name strings, and then write out a new GPT, the disk GUID is needed. While there is an existing accessor for the partition UUIDs, there is none yet for the disk GUID. Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com>
|
#
db9b6200 |
|
25-Jun-2017 |
Alison Chaiken <alison@peloton-tech.com> |
EFI: replace number with UUID_STR_LEN macro Changes since v6: none. Signed-off-by: Alison Chaiken <alison@peloton-tech.com>
|
#
02e43537 |
|
01-Mar-2017 |
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> |
part_efi: support padding between the GPT header and partition entries Some architectures require their SPL loader at a fixed address within the first 16KB of the disk. To avoid an overlap with the partition entries of the EFI partition table, the first safe offset (in bytes, from the start of the device) for the entries can be set through CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig) When formatting a device with an EFI partition table, we may need to leave a gap between the GPT header (always in LBA 1) and the partition entries. The GPT header already contains a field to specify the on-disk location, which has so far always been set to LBA 2. With this change, a configurable offset will be translated into a LBA address indicating where to put the entries. Now also allows an override via device-tree using a config-node (see doc/device-tree-bindings/config.txt for documentation). Tested (exporting an internal MMC formatted with this) against Linux, MacOS X and Windows. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: __maybe_unused on config_offset to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
9da52f8f |
|
27-Feb-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
gpt: Fix uuid string format Change GPT UUID string format from UUID to GUID per specification. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e163a931 |
|
30-Jan-2017 |
Vincent Tinelli <vincent.tinelli@intel.com> |
cmd: gpt: backup boot code before writing MBR On some cases the first 440 bytes of MBR are used to keep an additional information for ROM boot loader. 'gpt write' command doesn't preserve that area and makes boot code gone. Preserve boot code area when run 'gpt write' command. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Brennan Ashton <brn@deako.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
b331cd62 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@st.com> |
cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly update all of the config files we must also update CMD_PART and CMD_GPT to also be in Kconfig in order to avoid complex logic elsewhere to update all of the config files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
bd42a942 |
|
27-Jan-2017 |
Patrick Delaunay <patrick.delaunay@st.com> |
disk: convert CONFIG_EFI_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
|
#
87b8530f |
|
09-Sep-2016 |
Petr Kulhavy <brain@jikos.cz> |
disk: part: implement generic function part_get_info_by_name() So far partition search by name has been supported only on the EFI partition table. This patch extends the search to all partition tables. Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from part_efi.c into part.c and make it a generic function which traverses all part drivers and searches all partitions (in the order given by the linked list). For this a new variable struct part_driver.max_entries is added, which limits the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS. Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables. Signed-off-by: Petr Kulhavy <brain@jikos.cz> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Steve Rae <steve.rae@raedomain.com>
|
#
c2fdd345 |
|
28-Jul-2016 |
Kever Yang <kever.yang@rock-chips.com> |
cmd: gpt: fix the wrong size parse for the last partition The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for size '-', because both fist_usable_lba and last_usable_lba will remain 34 sectors. We can simply use 0 for size '-' because the part_efi module will decode the size and auto extend the size to maximum available size. Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
|
#
5afb8d15 |
|
22-Jul-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Fix compiler warning on 32-bit sandbox This fixes a mismatch between the %zu format and the type used on sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
a5653867 |
|
02-May-2016 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
disk: part_efi: fix check of the max partition size the last value acceptable value for offset is last_usable_lba + 1 and not last_usable_lba - 1 issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- create GPT partion on all the card > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- try to recreate the same partition with the next command (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) in the code : /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! but the test (offset >= last_usable_lba) cause the error END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>disk: part_efi: fix check of the max partition size the last value acceptable value for offset is (last_usable_lba + 1) and not (last_usable_lba - 1) issue found with SDCARD partition commands on u-boot 2015.10 but this part of code don't change 1- I create GPT partion on all the card (start and size undefined) > gpt write mmc 0 name=test,start=0,size=0 > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fde "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: b710eb04-45b9-e94a-8d0b-21458d596f54 => Start = 0x22*512 = 0x4400 => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00 2- I try to recreate the same partition with the command gpt write and with start and size values (block size:512 bytes = 0x200) > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800 Writing GPT: Partitions layout exceds disk size > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600 Writing GPT: success! I check the partition created : > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x003a9fdc "test" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0 => but the max LBA when the size is indicated (0x003a9fdc) is lower than when u-boot compute the max allowed value with size=0 (0x003a9fde) 3- in the code, just after my patch, line 446 /* partition ending lba */ if ((i == parts - 1) && (partitions[i].size == 0)) /* extend the last partition to maximuim */ gpt_e[i].ending_lba = gpt_h->last_usable_lba; else gpt_e[i].ending_lba = cpu_to_le64(offset - 1); so offset = gpt_h->last_usable_lba + 1 is acceptable ! (it the value used when size is 0) but today the test (offset >= last_usable_lba) cause the error my patch only solve this issue END Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
|
#
4708a07c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop NULL check in part_get_info_efi() This cannot be NULL since part_get_info() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138497) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
5f095f0c |
|
16-Mar-2016 |
Simon Glass <sjg@chromium.org> |
part_efi: Drop the NULL check on dev_desc in part_print_efi() This cannot be NULL since part_print() calls this function and requires it to be non-NULL. Reported-by: Coverity (CID: 138498) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
084bf4c2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
part: Rename test_part_xx() and print_part_xx() Rename these functions so that part_ is at the start. This more clearly identifies these functions as partition functions. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
2a981dc2 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Adjust device calls to go through helpers function To ease conversion to driver model, add helper functions which deal with calling each block device method. With driver model we can reimplement these functions with the same arguments. Use inline functions to avoid increasing code size on some boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
|
#
bcce53d0 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: block: Rename device number member dev to devnum This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
|
#
3e8bd469 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Rename some partition functions Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com>
|
#
96e5b03c |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Convert partition API use to linker lists We can use linker lists instead of explicitly declaring each function. This makes the code shorter by avoiding switch() statements and lots of header file declarations. While this does clean up the code it introduces a few code issues with SPL. SPL never needs to print partition information since this all happens from commands. SPL mostly doesn't need to obtain information about a partition either, except in a few cases. Add these cases so that the code will be dropped from each partition driver when not needed. This avoids code bloat. I think this is still a win, since it is not a bad thing to be explicit about which features are used in SPL. But others may like to weigh in. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@nvidia.com>
|
#
f8d6165d |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: part: Correct a sandbox build warning Adjust the cast to avoid a warning when stdint.h is used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com>
|
#
4101f687 |
|
29-Feb-2016 |
Simon Glass <sjg@chromium.org> |
dm: Drop the block_dev_desc_t typedef Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
|
#
192bc694 |
|
30-Dec-2015 |
Ben Whitten <ben.whitten@gmail.com> |
Fix GCC format-security errors and convert sprintfs. With format-security errors turned on, GCC picks up the use of sprintf with a format parameter not being a string literal. Simple uses of sprintf are also converted to use strcpy. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7c4213f6 |
|
07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
block: pass block dev not num to read/write/erase() This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
cfdaf4ca |
|
17-Nov-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
part:efi: add bootable parameter in gpt command The optional parameter bootable is added in gpt command to set the partition attribute flag "Legacy BIOS bootable" This flag is used in extlinux and so in with distro to select the boot partition where is located the configuration file (please check out doc/README.distro for details). With this parameter, U-Boot can be used to create the boot partition needed for device using distro. example of use: setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\ name=rootfs,size=0" > gpt write mmc 0 $partitions > part list mmc 0 Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0001e021 "u-boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: cceb0b18-39cb-d547-9db7-03b405fa77d4 2 0x0001e022 0x0003c021 "boot" attrs: 0x0000000000000004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: d4981a2b-0478-544e-9607-7fd3c651068d 3 0x0003c022 0x003a9fde "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 6d6c9a36-e919-264d-a9ee-bd00379686c7 > part list mmc 0 -bootable devplist > printenv devplist devplist=2 Then the distro scripts will search extlinux in partition 2 and not in the first partition. Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
|
#
cef68bf9 |
|
20-Nov-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
gpt: part: Definition and declaration of GPT verification functions This commit provides definition and declaration of GPT verification functions - namely gpt_verify_headers() and gpt_verify_partitions(). The former is used to only check CRC32 of GPT's header and PTEs. The latter examines each partition entry and compare attributes such as: name, start offset and size with ones provided at '$partitions' env variable. Signed-off-by: Lukasz Majewski <l.majewski@majess.pl> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com>
|
#
bcb41dca |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
uuid: add selection by string for known partition type GUID short strings can be used in type parameter of gpt command to replace the guid string for the types known by u-boot partitions = name=boot,size=0x6bc00,type=data; \ name=root,size=0x7538ba00,type=linux; gpt write mmc 0 $partitions and they are also used to display the type of partition in "part list" command Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000022 0x0000037f "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2 2 0x00000380 0x003a9fdc "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 25718777-d0ad-7443-9e60-02cb591c9737 Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
|
#
7561b258 |
|
27-Oct-2015 |
Patrick Delaunay <patrick.delaunay73@gmail.com> |
gpt: add optional parameter type in gpt command code under flag CONFIG_PARTITION_TYPE_GUID add parameter "type" to select partition type guid example of use with gpt command : partitions = uuid_disk=${uuid_gpt_disk}; \ name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \ name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \ type=0fc63daf-8483-4772-8e79-3d69d8477de4; gpt write mmc 0 $partitions Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
|
#
cf92e05c |
|
02-Sep-2015 |
Simon Glass <sjg@chromium.org> |
Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
b349abbf |
|
07-Jan-2015 |
Maxime Ripard <maxime.ripard@free-electrons.com> |
gpt: Fix the protective MBR partition size According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
#
0ff7e585 |
|
12-Dec-2014 |
Steve Rae <srae@broadcom.com> |
fastboot: handle flash write to GPT partitions Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2]
|
#
e1f6b0a0 |
|
17-Dec-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: move code to static functions Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2]
|
#
e48f3741 |
|
11-Nov-2014 |
Simon Glass <sjg@chromium.org> |
sandbox: Fix warnings due to 64-bit printf() strings Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
60bf9416 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add get_partition_info_efi_by_name() Add function to find a GPT table entry by name. Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com>
|
#
e04350d2 |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: clarify lbaint_t usage - update the comments regarding lbaint_t usage - cleanup casting of values related to the lbaint_t type - cleanup of a type that requires a u64 Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com>
|
#
dedf37bb |
|
26-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: resolve endianness issues Tested on little endian ARMv7 and ARMv8 configurations Signed-off-by: Steve Rae <srae@broadcom.com>
|
#
ae95fad5 |
|
05-May-2014 |
Steve Rae <srae@broadcom.com> |
disk: part_efi: add support for the Backup GPT Check the Backup GPT table if the Primary GPT table is invalid. Renamed "Secondary GPT" to "Backup GPT" as per: UEFI Specification (Version 2.3.1, Errata A) Signed-off-by: Steve Rae <srae@broadcom.com>
|
#
d718ded0 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
lib: uuid: code refactor for proper maintain between uuid bin and string Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be This patch also updates functions calls and declarations in a whole code. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com
|
#
a96a0e61 |
|
02-Apr-2014 |
Przemyslaw Marczak <p.marczak@samsung.com> |
part_efi: move uuid<->string conversion functions into lib/uuid.c This commit introduces cleanup for uuid library. Changes: - move uuid<->string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. - rename uuid_string() to uuid_bin_to_str() for consistency with existing uuid_str_to_bin() - add an error return code to uuid_str_to_bin() - update existing code to the new library functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: trini@ti.com
|
#
61fcc7d2 |
|
13-Feb-2014 |
Hector Palacios <hector.palacios@digi.com> |
part_efi: fix protective mbr struct allocation The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Signed-off-by: Hector Palacios <hector.palacios@digi.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
#
6d2ee5a3 |
|
10-Sep-2013 |
Mark Langsdorf <mark.langsdorf@calxeda.com> |
part_efi: make sure the gpt_pte is freed the gpt_pte wasn't being freed if it was checked against an invalid partition. The resulting memory leakage could make it impossible to repeatedly attempt to load non-existent files in a script. Also, downgrade the message for not finding an invalid partition from a printf() to a debug() so as to minimize message spam in perfectly normal situations. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
|
#
1a459660 |
|
08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
|
#
04735e9c |
|
26-Jun-2013 |
Frederic Leroy <fredo@starox.org> |
Fix ext2/ext4 filesystem accesses beyond 2TiB With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org>
|
#
67cd4a63 |
|
18-May-2013 |
Marek Vasut <marex@denx.de> |
disk: Fix possible out-of-bounds access in part_efi.c Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org>
|
#
ae1768a7 |
|
09-Apr-2013 |
Egbert Eich <eich@suse.com> |
disk/gpt: Fix GPT partition handling for blocksize != 512 Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of code in u-boot still assumes a 512 byte blocksize. This patch fixes the handling of GPTs. Signed-off-by: Egbert Eich <eich@suse.com>
|
#
8faefadb |
|
29-Mar-2013 |
Marc Dietrich <marvin24@gmx.de> |
disk: fix unaligned access in efi partitions start_sect is not aligned to a 4 byte boundary thus causing exceptions on ARM platforms. Access this field via the get_unaligned_le32 macro. Signed-off-by: Marc Dietrich <marvin24@gmx.de>
|
#
2c1af9dc |
|
28-Feb-2013 |
Stephen Warren <swarren@nvidia.com> |
disk: define HAVE_BLOCK_DEVICE in a common place This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
|
#
40684ddb |
|
11-Dec-2012 |
Lukasz Majewski <l.majewski@samsung.com> |
gpt: Support for GPT (GUID Partition Table) restoration The restoration of GPT table (both primary and secondary) is now possible. Function 'gpt_restore' presents example of partition restoration process. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
#
fae2bf22 |
|
11-Dec-2012 |
Chang Hyun Park <heartinpiece@outlook.com> |
gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h> Custom definitions of le_XX_to_int functions have been replaced with standard ones, defined at <compiler.h> Replacement of several GPT related structures members with ones indicating its endianness and proper size. Signed-off-by: Chang Hyun Park <heartinpiece@outlook.com> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
#
9936be31 |
|
12-Oct-2012 |
Taylor Hutt <thutt@chromium.org> |
disk: Address cast and format errors This change addresses a few printf-formatting errors, and a typecast error. Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
b4414f4a |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: set bootable flag in partition objects A partition is considered bootable if it either has the "legacy BIOS bootable" flag set, or if the partition type UUID matches the standard "system" type. Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
13bf2f55 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print raw partition attributes When printing the EFI partition table, print the raw attributes. Convert struct gpt_entry_attributes to a union to allow raw access. Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
f07cd2c4 |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: print partition UUIDs When printing the partition table, print the partition type UUID and the individual partition UUID. Do this unconditionally, since partition UUIDs are useful. Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
788a8c1f |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: re-order partition list printf, change case The partition name is a long variable-length string. Move it last on the line to ensure consistent layout and that the entries align with the "header" line. Also, surround it in quotes, so if it's empty, it's obvious that something is still being printed. Also, change the case of the LBA numbers; lower-case looks nicer in my opinion, and will be more consistent with the UUID printing that is added later in this series. Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
38a3021e |
|
08-Oct-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: remove indent level from loop Simplify the partition printing loop in print_part_efi() to bail out early when the first invalid partition is found, rather than indenting the whole body of the loop. This simplifies later patches. Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
894bfbbf |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: parse and store partition UUID Each EFI partition table entry contains a UUID. Extend U-Boot's struct disk_partition to be able to store this information, and modify get_partition_info_efi() to fill it in. The implementation of uuid_string() was derived from the Linux kernel, tag v3.6-rc4 file lib/vsprintf.c function uuid_string(). Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
c04d68c6 |
|
21-Sep-2012 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: range-check partition number Enhance get_partition_info_efi() to range-check the partition number. This prevents invalid partitions being accessed, and prevents access beyond the end of the gpt_pte[] array. Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
#
b37d41aa |
|
04-Mar-2012 |
Marek Vasut <marex@denx.de> |
Block: Remove MG DISK support This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com>
|
#
29b7042a |
|
16-Nov-2011 |
Sanjeev Premi <premi@ti.com> |
part_efi: Fix compile errors Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
#
4715a811 |
|
28-Oct-2011 |
Stephen Warren <swarren@nvidia.com> |
disk: part_efi: fix regression due to incorrect buffer usage Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org>
|
#
deb5ca80 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org>
|
#
df70b1c2 |
|
19-Oct-2011 |
Doug Anderson <dianders@chromium.org> |
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org>
|
#
f75dd584 |
|
12-Oct-2011 |
Anton staaf <robotboy@chromium.org> |
part_efi: dcache: allocate cacheline aligned buffers Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org>
|
#
6eecc030 |
|
07-Sep-2011 |
Lei Wen <leiwen@marvell.com> |
part: show efi partition name when print out partition info Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com>
|
#
71665528 |
|
28-Jul-2009 |
Wolfgang Denk <wd@denx.de> |
Partition support: remove newline from partition name Remove bogus newline character that got added to the .name field of the disk_partition_t structure. Signed-off-by: Wolfgang Denk <wd@denx.de>
|
#
75eb82ec |
|
24-Feb-2009 |
unsik Kim <donari75@gmail.com> |
mflash: Initial mflash support Mflash is fusion memory device mainly targeted consumer eletronic and mobile phone. Internally, it have nand flash and other hardware logics and supports some different operation (ATA, IO, XIP) modes. IO mode is custom mode for the host that doesn't have IDE interface. (Many mobile targeted SoC doesn't have IDE bus) This driver support mflash IO mode. Followings are brief descriptions about IO mode. 1. IO mode based on ATA protocol and uses some custom command. (read confirm, write confirm) 2. IO mode uses SRAM bus interface. Signed-off-by: unsik Kim <donari75@gmail.com>
|
#
7bd2722e |
|
29-Jan-2009 |
Mike Frysinger <vapier@gentoo.org> |
disk: convert part_* files to COBJ-$(CONFIG_XXX) style Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
#
50970839 |
|
26-Jan-2009 |
Richard Retanubun <RichardRetanubun@RuggedCom.com> |
part_efi: Fix partition size calculation due to inclusive ending LBA. The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com>
|
#
6d0f6bcf |
|
16-Oct-2008 |
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> |
rename CFG_ macros to CONFIG_SYS Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
#
07f3d789 |
|
26-Sep-2008 |
richardretanubun <richardretanubun@ruggedcom.com> |
Add support for CONFIG_EFI_PARTITION (GUID Partition Table) The GUID (Globally Unique Identifier) Partition Table (GPT) is a part of EFI. See http://en.wikipedia.org/wiki/GUID_Partition_Table Based on linux/fs/partitions/efi.[ch] Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com>
|